Я - тимлид быстрорастущей группы системных аналитиков в Lamoda. За последний год мы выросли в 3 раза с 3 системных аналитиков до 9. За это время я была на 60+ собеседованиях, в процессе которых я знакомлюсь с разными системными и бизнес аналитиками, а также подходами к системному анализу в разных компаниях.
Я работаю в системном анализе 10 лет. 5 лет работала в ЛАНИТ на проектах ЕМИАС, с проектами РСА (единая база ОСАГО, электронный ОСАГО, бюро страховых историй), ЦБ, крупных банков.
Вторые 5 лет я работаю в Lamoda. В Lamoda помогала запускать новые сервисы, связанные с различными методами оплаты, рефакторила процесс возврата денежных средств, запускали систему доставки в Казахстане и многое другое.
Сейчас занимаюсь развитием нашего отдела и немного проектной деятельностью.
В личной жизни обожаю проводить время с дочкой и мужем. Люблю искусство в любом его проявлении и спорт.

Опыт спикера:
2 доклада внутри Lamoda (ссылки кидать не могу),
1 доклад в 2020 году на конференциях Knoleadge conf и ЛАФ:
https://knowledgeconf.ru/2020/abstracts/6758
https://conf.uml2.ru/index.php?all_classes&class_id=kak-pisat-kachestvennyi-tekst

1. интервьюировать заказчика
2. выявлять требования к решению
3. применять продуктовый подход (или нет)
4. презентовать концепцию решения заказчику

1. Знакомство с правилами игры. Вы узнаете правила игры и познакомитесь с помощником, который будет сопровождать и поддерживать вашу команду во время игрового проекта.
2. Интервью с заказчиком. Каждая команда по очереди проведет интервью с заказчиком и получит ответы на заданные вопросы.
3. Анализ требований и хотелок. После интервью у команды будет время на анализ полученной информации и разработку границ проекта.
4. Проектирование решения. Концепция, а может быть сразу ТЗ? Все в ваших руках.
5. Документирование решения. Способ документирования выбирает команда. Разрешены даже комиксы. Никаких ГОСТов, но, если хочется, то и их тоже можно.
6. Подготовка к презентации и представление результатов. У команды будет время подготовиться, организовать встречу с заказчиком и рассказать о своем решении.

А так же, заданий на скорость, силу, ловкость и сообразительность. Обратная связь от заказчика гарантируется!

Будет организована запись на эстафету. Количество мест ограничено. Для участия вы можете собрать команду заранее или объединиться перед стартом.

Жил был продукт для больших компаний. С хорошей документацией, которую команда вела в конфлюенс.
Продукт рос, документация пухла, но оставалась хорошей.
Число заказчиков тоже увеличивалось, а под каждого заказчика появлялось новое пространство с описанием продукта — с одной стороны, унаследованном от общей документации, а с другой — описывающее специфичные для заказчика доработки и настройки.
В какой-то момент выросшая документация выросла настолько, что вышла из-под родительского контроля команды:

• Перестала быть понятной для заказчиков — где их настройки, а где общие, что и как нужно использовать для интеграции с системой.
• Постоянно требовала внимания и актуализации.
• Каждое пространство стремилось стать уникальным по своей структуре и выделиться на фоне остальных.
• При изменениях в ядре продукта все простанства требовали актуализации одновременно.

Но команда не растерялась и отправила документацию на лечение.
О проведенном процессе исцелении я и расскажу в докладе:

1. Как мы переработали структуру нашей документации.
2. Как автоматизировали создание и обновления описания самых больных разделов:

•  модели данных;
•  задач по обработке данных внутри приложения, их параметров;
•  пакетов задач и их расписания;
•  примеров запросов к API;
•  release notes для заказчика.

1. Каких успехов уже достигли:

•     уменьшили число обращений от заказчиков из-за неактуальной документации;
•     упростили поддержку и поиск;
•     стали больше доверять нашей документации;
•     ускорили передачу поддержки заказчиков между коллегами.

1. С какими техническими и организационными проблемами столкнулись в процессе оздоровления и что планируем сделать в ближайшем будущем.

Аналитическая мастерская с щепоткой рефлексии — 1.5 часа
 

Аннотация

Вы знаете наизусть все Джедайские техники, с точностью до минуты определяете оставшееся время на поммодоро-таймере, списки и чек-листы подготовлены на все случаи жизни... но что-то идет не так, и времени в сутках все еще не хватает, списки дел пухнут и пухнут? Двери нашего клуба открыты для вас.

Вы не знаете ни одной техники тайм-менеджмента, но лавина дел накрывает с головой, а вокруг все такие эффективные и супер-деятельные….и вам добро пожаловать в наш клуб!

 

Мы вместе попробуем найти причины нехватки времени. А может вы поймете, что вы уже все успеваете? Разберем различные техники тайм-менеджмента и выясним, когда они не работают, а когда приносят результат.

Спойлер — на утюге можно жарить яичницу, но предназначен он для глажки белья) Так и с техниками. Пример, не надо ждать от блока помодорро результатов для творческих и исследовательских задач, потому что нельзя сказать мозгу «вот тебе 3 раза по 25 минут, быстренько выдай гениальную идею, а то мне пора переходить к следующей задаче».

 

Что вас ждет:

1. Индивидуальная работа со списком дел и рефлексия.
2. Групповые активности по разбору техник тайм-менеджмента.
3. Теплая, ламповая поддержка и понимание :-)
4. Составленный план дел на следующую неделю.

 

Предварительная подготовка. Эти материалы только для вас. Мне или всем их показывать не надо. Но они помогут понять вам, где и что пошло не так:

1. Будет отлично, если вы придете с перечнем дел за последние 3-7 дней в хронологическом порядке. Учитывайте все, даже «полистал ленту фейсбука», «почистил зубы» и «поставил задачу в джира».
2. Напишите, что за последнюю неделю вы хотели успеть сделать, но не успели. Или чем недовольны — просчитались в оценке, забыли, недоделали.

Мой доклад о моем опыте создания интересного интеграционного решения, в котором я участвовала на протяжении последних полутора лет в качестве аналитика. Я расскажу, какие именно подходы мы применяли, и, почему решили создать API, зачем наше API пользователям, и какие преимущества оно им дает. А также, об особенностях работы и возможных трудностях аналитика при участии в таком интеграционном проекте.

Тестовый мастер-класс

Существует пять универсальных требований, применимых к любым информационным системам, работающим с большими данными. За 20 минут посмотрим, что это за требования, почему они не важны пока данные «маленькие», но стремительно поднимаются в приоритете с переходом к парадигме Big Data. Аналитики, осваивающие работу с Big Data, смогут добавить их в свой чек-лист для проверки полноты требований. А опытным специалистам, работающим с большими массивами данных не первый год, будет любопытно узнать, что бета-версия этого набора требований была сформулирована еще в Древнем Риме.

Мастер-класс на 4 часа, основанный на однодневном тренинговом модуле, который мы с коллегами второй год ведём для студентов Высшей Школы Экономики. Тренинг в свою очередь основан на нашем опыте работы со сложными системами, где каждое требование к продукту влечет согласованную работу нескольких команд.

Что такое АГИЛ - это Agile, когда есть нюанс (как в анекдоте), а то и несколько. То есть, когда итерации короткие, требования изменчивые, команды самоорганизованы в бандитские шайки из-за тупого и ленивого менеджмента, а вот всё остальное - как придётся.
Всё то же самое применимо и в Agile, но там обчно есть Agile Coach, который обязательно внедрит SAFe, LeSS и много других страшных слов.

Вся теория к мастер-классу и полное описание проблематики находится в докладе "Требования в АГИЛ для сложного сервиса (теория) - можно посмотреть описание доклада отдельно.

На мастер-классе я хочу показать вариант целостного процесса превращения творческих идей по сервису в конечные тикеты на каждого разработчика.
Сам процесс включает в себя практики, с которыми полезно познакомиться любому аналитику:
- Отображение продуктовых требований с помощью бизнес-канваса и связанных с ним инструментов
- Поиск точек изменения с помощью карты и эскиза процессов
- Двумерный мапинг историй для выявления требований
- Применение карт влияния (Impact mapping) совместно с двумерным мапингом или без него
- Изображение системного ландшафта и архитектуры в стиле 4Context
- Сценарии или диаграммы взаимодействия
- И снова карты влияния для раздачи задач системам, командам и отдельным исполнителям
- Согласованная нарезка бэклогов команд на итерации и осознанное - с учётом архитектуры - расщепление историй для максимально раннего получения бизнес-ценности
- Реверс процесса - что мы получим, если (не) сделаем эти задачи

Максимальное число работающих руками - 2 команды по 6 человек. Остальные могут быть зрителями и присоединиться к обсуждению.